Early and Extended Function Point: a new method for Function Points estimation

As a consequence of the wider use of the Function Point metrics in the software management field there is an increasing need for methods to estimate in an early stage of the software life cycle the number of Function Points related to a software application. The present paper describes a new technique to estimate Function Points (Early and Extended Function Points Method) and some experiences of its utilization. The application of the method allows to obtain two different measurements: Early Function Points (EFP) and Extended Function Points (XFP). Early Function Points are not a measurement alternative to IFPUG 4.0 Function Points, but only a fast estimate of the same. Therefore, no conversion factors are required between the two measures. The number of EFP should approximate the number of IFPUG 4.0 FP when both are calculated on the same user requirements. Extended Function Points derive from EFP after the application of two corrective factors relative to software reuse and algorithmic complexity. XFP are not compatible with IFPUG 4.0 FP, since these aspects are currently neglected by IFPUG standards, but nevertheless they can be used for more accurate productivity evaluations. This paper underlines, as well, the need of an improvement to the standard IFPUG models and rules to consider properly three factors, two of which were cited before: software reuse, algorithmic complexity and indipendence from non-functional characteristics. Firstly, today’s technologies (DBMS, CASE, O.O.,...) make it possible to reuse a great amount of software modules or data already available in a particular technical environment. It is even possible to buy on the market many components ready to use and to be incorporated in a custom software project. It becomes so necessary to distinguish between FP asked by and released to the user and FP actually developed by the software team. For contractual reasons the first number is probably the one to use whereas for project managing ends and productivity considerations the second one appears to be more representative of the reality being measured. Secondly it should be noticed that till now there has been a certain skepticism in applying Function Point Analysis to software areas different from that of typical business information systems (i.e. telecommunications, real time control, operating system software). The reason generally reported is that a ‘technical’ software is more centered on complex data items processing than on a user inputoutput transaction basis and that this fact is not properly considered by the IFPUG models and rules. Using the XFP approach presented here it is possible to take in account this aspect in assigning weights to the different functionalities of the software application under measurement. Thirdly we support the thesis that it is necessary to exclude the General System Characteristics (GSC) from the capability to influence the final number of Function Points if we seek for a (almost) pure functional measure of the software size. Function Points should not be a direct measure of effort. On the other hand if we would like to derive effort from FP than we would need more than the standard 14 GSC and each one with a different capability of influencing the result (not only by +/-5%). The paper includes the results of real estimation experiences occurred in some major Italian companies comparing the counts obtained according to IFPUG 4.0 standards with the EFP estimates showing their strong correlation. We then make a summary comparison of the proposed method with other estimation techniques or extentions available in the technical community. The Early and Extended FP method along with the IFPUG 4.0 one were implemented in a business tool called Sfera herein briefly described.